XAnim also provides various options that allow the user to alter colormaps, playback speeds, looping modes and can provide on-the-fly scaling of animations with the mouse.
In each SubMenu, the options can be run together with no intervening spaces. In the list of SubMenu options presented below, the first letter given is the letter that specifies the SubMenu and should NOT be repeated if several SubMenu options are to be run together.
For example, "+Cn +Cs10 +CF4" can also be written as "+Cns10F4" or "+CF4s10n".
A + or a - within a SubMenu will be an exit from that submenu. Options will affect all animations following the invocation of that option. Some options may be changed in between animations without affecting previous animations.
In the following sections, an num represents an integer number and an fnum represents a floating point number. If a floating point number is of an integer amount, the . need not be specified. There should be no spaces between the option and the numbers.
aopts SubMenu for Audio Options
copts SubMenu for Color Options
gopts SubMenu for Gamma Options
mopts SubMenu for Median-Cut Quantization Options
sopts SubMenu for Scaling Options
Normal Options
Once the animation is up and running there are various commands that can be entered into that animation window from the keyboard.
Once the animation is up and running the mouse buttons have the following functions.
XAnim by default will read the entire animation into memory. DL, PFX, Moviesetter, GIF or URT RLE type animations are always uncompressed and stored in memory as individual images.
For the AVI, QT, IFF, FLI/FLC animations, only the compressed delta is stored. These deltas are then uncompressed each time they need to be displayed. The buffer option(+b) may be used to potentially speed up playback by uncompressing and storing these images ahead of time. But more memory is used up in the process.
When an XPutImage is called, the image typically gets copied twice, once to memory and then from there onto the display. A pixmap is directly copied onto the display without the first copy. This is why it is sometimes much faster to use the pixmap option(+p). Each image isn't converted into a pixmap until the first time it is displayed. This is why the first loop of an animation using this option is sometimes slower than subsequent loops. While the pixmap option may improve playback speed, it will slow things down if on-the-fly scaling needs to be performed. This is because XAnim no longer has direct access to the image and needs to get a copy of it before it can be scaled.
The read from file option(+f) causes xanim not to store the compressed deltas in memory. Instead as each image is to be displayed, xanim reads the corresponding compressed delta from the file, expands it and then displays it. While this can dramatically cut down on memory usage, the necessary reads from disk(or whatever) can slow down playback speed. XAnim still needs to allocate one to three image buffers depending on the type of animation and the scaling options used. This option is only supported for AVI, QT, FLI/FLC and IFF animations. The BODY chunk of IFF animations is not included in this. As a result, an IFF animation that is made up of several BODY chunks will not currently benefit from this option.
There are two sets of scaling options. One set, the display scaling factors, affects the size of the animation as it is displayed. The other set, the buffer scaling factors, affect the size of the images as they are stored in memory(buffered). The buffer scaling factors only affect animations that are buffered and can greatly increase or decrease memory usage.
These two sets are completely independent of each other. You can set the buffer scaling factors to 20 times the normal animation size and not affect the size at which that animation is displayed. The images are stored at 20 times the normal size(and at 400 times the memory usage), but then get scaled back down to normal size before being displayed. NOTE: that an animation must be buffered in order for the buffer scaling factors to have any affect on it. The display scaling factors affect all animations.
You can create pixellation like affects by buffering the animation at 1/8 it's normal size, but keeping the display scaling factors at the original size. (IE "xanim +bSS0.125 anim.anim").
Many times it's faster to store and display an animation with large dimensions at half-size. The option "+bSS0.5C" or "+bSS0.5s0.5" both will accomplish this. To save memory, you could even store the animation at half size and yet display it at full size. "+bSS0.5" will accomplish this.
Many type of animations(FLI/FLC/IFF/some AVI and QTs) are compressed with forward playback in mind only. Each delta only stores the difference between the current frame and the previous frame. As a results, most of these animations don't display correctly when played backwards. Even when buffered up, these may not work, since XAnim only stores the smallest rectangle that encompasses the changes from the previous frame. You can force XAnim to store the entire frame by specifying the "-o" option to turn this optimization off. This will most likely use more memory and slow down the animation, since more of the image needs to be stored and/or displayed.
Most of this will be a TBD for a future rev and what's here might be sketchy, incomplete or just plain confusing.
TrueColor and DirectColor displays don't need to worry about most of these options, as the animations can be displayed in their original colors(ignoring monitor variations etc). However, TrueColor and DirectColor displays can't display animations that employ color cycling techniques where the colormap changes from frame to frame. DirectColor could potentially support this, but not TrueColor.
For the rest of the displays, the problem becomes matching the colors in the animations to the available colors of the Display. For most PseudoColor displays this means 256 colors. Many of which are already in use by various other programs. XAnim defaults to creating it's own colormap and using all the colors from that. The window manager then installs this new colormap, whenever the mouse pointer is inside the XAnim animation window(Sometimes a specific action is required to change the ColorMap Focus, like clicking in the window or pressing a specific key). In any case, this action usually causes all the other colors on the screen to be temporarily "messed-up" until the mouse is moved out of the animation window. The alternative, is to use the "+Cn" option. Now XAnim tries allocating all the colors it needs from the current colormap. If it can't get a certain color, then XAnim choose one that is "close" to this certain color. Close is completely arbitrary. The animation is now displayed in colors that are different than the original colors. This difference may or may not be noticeable.
Another big problem is when the animations are what I called TrueColor animations. Where each pixel is stored as RGB triplets. For example, AVI 16 bit CRAM animations. Each pixel has 5 bits of Red, 5 bits of Green and 5 bits of Blue info associated with it. This means there can be up to 32768 unique colors in each image. And on most PseudoColor displays we can only display 256 unique colors. Beside getting better displays, what can we do? XAnim defaults to truncating the RGB information from 555 to 332. That is to 3 bits of Red, 3 bits of Green and 2 bits of Blue. Less on Blue because the human eye is more sensitive to Red and Green than Blue. This 332 colormap happens to be 256 colors in size, which nicely fits in with our display. If our display only had 64 colors, then XAnim is smart enough to truncate things down to 222. Now the problem is the colors of the displayed anim are noticeably different than the original colors. Typically you can see color banding etc. While this is fine to get a feel for the animation, we can do better. One of the solutions XAnim currently offers is the "+bC1" option. What this does is choose the the best 256 colors from the first image of the animation. Then each pixel of each subsequent image is remapped to one of these 256 colors. This takes up some CPU time up front and more memory since each image needs to be buffered, but results in a colors that are closer to the originals. Another option, "+bCA", chooses the best 256 from each image, then 256 colors from all these colormaps are chosen as the final colormap. This is useful if the colors in the first image aren't representative of the rest of the animation. This can be very slow. Another option that is supported, but not really optimized for yet is "+bC3dm". This causes XAnim to use a 332 colormap and then apply a Floyd-Steinberg dither algorithm to each image. Currently this is very slow. Different dithers(like Ordered) and better optimizations might speed this up in future revs. In general, handling of TrueColor animations in XAnim needs to be improved.
Another scenario where colors need to be remapped, is when several images or animations with different colormaps need to be displayed. Changing the colormap usually results in an annoying flicker. One solution to this is to remap all of the images/animations to the same colormap. The "+Ca" option chooses the best colors from all the colormaps and then remaps all the images to it. The "+Cf" option, simply remaps everything to the first colormap. The "+Ch" option is useful when an animation's colormap specifies a lot of colors that aren't used. XAnim looks through each buffered image of the animation and makes a histogram of the useage of each color. This information is then used to weedout unused or rarely used colors.
Quicktime animations are usually stored in two separate files. One is call a data fork and ends with a ".data". The other is a resource fork and ends in a ".rsrc". Sometimes these animations are in a "flattened" format, where everything is put into one file. There's no standard naming format for these types of files.
For example, if you have a quicktime animation made up of two files named: "spin.rsrc" and "spin.data", you can display them using Xanim with either of the following commands "xanim spin" or "xanim spin.rsrc". XAnim is smart enough to add/modfiy the ".rsrc" and ".data" endings as needed.
If you use AUFS from the Columbia Appletalk Package, then Macintosh files have their data fork stored in the expected place, and the resource fork is in a file with the same name in a .resource subdirectory. Therefore, if the data fork is in "spin", and the resource fork is in ".resource/spin", the movie can be displayed with "xanim spin".
For "flattened" quicktime animations, you need to specify the entire file name.
NOTE: XAnim may not support all SMC or RPZA quicktime animations. It'll print "unknown code variation XX" to the screen as it encounters these and move on to the next image of that animation.
Mark Podlipec - podlipec@wellfleet.com